Most modern computer software design is based on the concept of modularity: the idea that separating a large piece of software into its constituent parts makes development and maintenance of the system much easier to manage.
Client/Server architecture is a logical extension of this idea. In a client/server system not all of the modules need necessarily exist or execute on the same machine. The client, which might be simply a desktop personal computer, can request information or services from a server, which might be a high powered computer running a database program and managing the storage of a vast amount of data. In this way clients and servers can run separately on the hardware and software platforms most suitable for their functions while co-operating to perform a task. Alternatively both client and server applications may run on the same machine.
The client application commonly manages the user interface side of the task. It accepts and verifies data entered by the user, dispatches requests to server applications and sometimes executes business logic. The design and development of a client application is a complicated task in and of itself. However, using the popular Object Oriented programming paradigm this task can also be simplified and separated into its constituent parts.
The essential elements of each use case or task to be managed by the client application can be divided between three types of “objects” each containing its own data and methods. A View object is responsible for presentation details or the User Interface (UI), which is generally a Graphical User Interface (GUI). A controller or handler object is responsible for managing the execution and co-ordination aspects of the business case. Finally a Business Object Implementation object is responsible for the business data and business logic aspects of the process or use case.
The purpose of this division is to simplify the structure of the application and to remove contact between the UI and the business logic. FIG. 1 shows the typical inter-relationships between the Business Object Implementation object or Business Object(s) 10, the View object 20 and the Handler object or Handler 30.
The view essentially presents the data or business object but in theory is not concerned with the business logic (which operations are to be performed on that data or what it is for). The view is usually made up of GUI components, for example data display fields, data entry fields, menus and buttons. It is the view object or sub-system with which the user interacts. The user may enter some data, for example, and press a button.
The handler is responsible for the coordinating of the sequence of actions that need to be performed to implement the use case. The handler, which is always “listening” to the view for relevant events, is notified that the user has requested some action to be performed and passes the data and instructions for this action to the appropriate Business Object Implementation.
The Business Object Implementation object processes any business logic that may have been requested by the user. The View and Business Object Implementation objects can communicate directly to ascertain when the View should refresh itself, or their communication can be coordinated by the handler. The View then refreshes itself from the updated data provided by the Business Object Implementation and the user is presented with the results of their request.
It will be appreciated from this description that while the division of the client application into Business Object Implementation, View and Handler provides a conceptually simpler structure, the interactions between the objects or sub-systems must be carefully managed, planned and implemented.
In theory the design of the application is separated into three steps, namely view design, handler design and business object design. However in reality, because of the essential interrelationships between these sub-systems, developers often find themselves mixing these steps into one. Thus development and maintenance once again become complex and some of the advantages of using this model are lost.
It would be useful to have a model using this division of the essential elements of an application into Business Object Implementations, Views and Handlers which could isolate the GUI from any business logic to some extent and allow for substantially independent development of the three classes of object or sub-systems.